I was wondering if anyone knows about a timeline or expected release for C++20 support in C++/CLI. According to this answer in the microsoft developer community support is in development, but i couldn't find more information.
Background:
Me and my team are developing a simulation engine in C++. We were thinking about a wrapping layer in C++/CLI so we can use C# for the UI/Editor. This is similar to the architecture of some game engines, where the main functionality is implemented in C++ and the Editor is written in C# and there is some layer in between.
Because we would heavily rely on further support of C++/CLI, are there any alternatives for this kind of project?
We were expecting there is some more information on the Microsoft forums and websites, but have problems finding something that really fits our purposes.
Thanks in advance.
C++20 support, as well as support for C++11 threading, will be added in MSVC 2022 17.6.
From https://github.com/microsoft/STL/wiki/Changelog#expected-in-vs-2022-176-preview-1 :
The STL now supports /clr for C++11 multithreading (mutex, condition_variable, future, etc.) and C++17 parallel algorithms. Additionally, the STL now allows /clr to be used in C++20 mode, although this is not yet supported for production use. #3194 #3201
See tracking issue #3193 for a list of compiler bugs that affect these newly enabled /clr scenarios.
Note, as stated in the above quote, the C++20 with /clr is not ready for production. That will come in a later release, but there's no estimates on that yet.
Assuming MS keeps with their 3 month release cycle, 17.5 will be released in February, meaning 17.6 preview 1 will be available at the same time, with a general release in May.
Related
That is a broad question but I want to listen to your opinion.
Three options come to my mind, Delphi, C# and Java.
I have little experience with C#, but still my experience show that C# is not a RAD tool
compared to Delphi. It's more like Swing/Java.
I see nothing on earth that can compare with Delphi, its simple and easy-to-use component
model to build visual applications.
Java is very complicated when it comes to building visual applications.
Delphi, in its way, is too old and simply dead tool (my opinion). But with Delphi I can
build such an application in minutes and it will be reliable, fast and comfy to work with.
Is there an alternative to building Delphi-like visual applications, fast, easy today?
The application must show a screen with html info, play a sound and react to user who can click on buttons displayed on the screen (navigate).
Delphi is certainly not dead, not by a mile. While there were 2 releases around 2005 initially considered to be buggy (service packs greatly improved the situation), that has all changed since Borland sold their developer tools division to Embarcadero.
Over the past 4 years, there have been 4 releases of the product, and each have been well received stable releases (Delphi 2007, 2009, 2010, and the latest: Delphi XE).
New features have recently been added in the past few years, including:
native generics
anonymous methods (aka closures)
full UNICODE support
support for touch/gesture features (for tablets, kiosks, and touchpads)
build process built on MSBuild
RTTI enhanced with attributes (language feature that allows annotating types and type members with special objects that carry additional information)
Excellent database support (as always) and updates for SQL Server 2008, MySQL, Firebird, Interbase, etc.
The next version (scheduled for release next year) will have a 32 and 64-bit compiler, and will support creating native executables for OS X, and will have a preview of native compilation for Linux. Check the roadmap for more details on this.
There also is a very active Delphi community here on SO, and around the web. Check out DelphiFeeds.com for a nice aggregation of Delphi news/blogs.
Delphi is not dead at all, but is actually looking better than ever now that it is under new management (Embarcadero) that actually seems to have the interest of developers as part of their business strategy!
--
Oh, and to answer your question, Delphi can do all of these things. Here are some links to get you started:
How to play a .wav file in Delphi
How to show Vista style balloon hints in Delphi?
Here's an alternative to balloon messages as well.
When you want to quickly create WIN32/Desktop applications with nice GUI's then Delphi is the best option. If you're doing web development, C# is a better alternative. If you want to be platform-independant, Java would be your best choice. If you're building device drivers, C++ is the best option.
Every programming language has a specific field where it excels when compared to other languages. Question is, in which field do you want to develop code?
As far as I know there is nothing compared to Delphi for Win32 RAD development. It's a shame that Delphi have lost it's credibility by changing names like what, 4 times in the last 10 years (Borland to Inprise then back to Borland then CodeGear and finally Embarcadero).
Delphi is definitively not dead but it's user base is not as strong as the Delphi 7 days. It's still a really nice and powerful product.
Delphi is not dead yet, it's being kind of updated (compiler especially). It has features in Win32 on par with what NET framework languages support - generics, anonymous methods, attributes. C# too can be used for designing simple apps fast, dunno why you find it complicated.
I'd go with Delphi, but I just like the language.
Do not use java for this kind of application, playing audio files will give nothing but problems.
Visual Studio is not exactly a raid tool, but there is a rich GUI builder and lots of built-in components, so you can create a GUI relatively fast. Connecting logic should not be a problem too.
If you are thinking Delphi, but only know C++, think Builder C++. Same RAD tool as Delphi but with a C++ compiler.
This isn't like new versions where newer versions will still have backwards compatibility.
What I mean is something like, when the designers of C#, .NET, CLR realize that they made a mistake or they overlooked something that could be hugely beneficial but now they couldn't pursue it because of backwards compatibility, they could branch the appropriate product say like by designating it in a different manner (horizontal versioning).
Wouldn't this be more future-proof?
You can say this would be a nightmare, but there would be restrictions like you can't mix and match different branches unlike the different languages that are compatible with each other, etc (in the same branch).
This way you would say use C# 4.0, then there is something very beneficial that you could use from C# 4.0 B1 (branch 1) and just use that, even though it might require some porting effort.
Is this not a healthy development strategy, where new projects could always start using the latest and the greatest, meaning the latest version and the latest branch of a particular language (C# 6.0 B4 for example)?
I don't see any extra hassle in keeping track of things for newer languages where you already have to know things for each version anyways. So this just adds another dimension (horizontal versions) to vertical versioning.
What would be the potential pros/cons for this development strategy?
There is a huge benefit to having a large set of libraries available for a platform. Currently, if I write a .NET 4.0 application I can reference libraries which were created way back on .NET 1.1. This means that there's a lot of existing code that I can take advantage of, and this is one of the major selling points of .NET.
If I understand your proposal correctly, then if library A is written against C# 4.0B1 and library B is written against C# 4.0B2, then there is no way that my application can be written to reference both library A and library B. This would fragment the platform and make it a much harder to justify the investment in writing C# applications or libraries.
Of course, there are also costs associated with backwards compatibility (look no further than Java's implementation of generics...), but in my opinion the benefits clearly outweigh them. Having a vibrant community using a language or platform makes it easier to hire developers, to find libraries with useful functionality, to get training and support, etc. These network effects are all put at risk by creating incompatible islands within the platform.
Actually, this is a bit like the way Open Source detractors used to argue Open Source projects would end up going. After all, you, I or anyone else could take any Open Source project and fork it into a different branch tomorrow.
Thankfully, the only case where this would gain any traction in the community though, is where we either took it into a specialist rôle (so that it didn't really compete with the original project, just builds on a common ancestor), or where there was massive dissatisfaction with the way the original project was run (where it's sort of a nuclear strike option in Open Source politics).
The reason it was used as a bogeyman argument against Open Source is that it would just be impossible to keep track of which version of which version of which version of which version of a given library, framework, language, component, etc. could work with which version of which version of which version of which version of another.
Luckily, whether open or closed, such branches would die a natural death in the face of the "market" (whether that market was economic or otherwise).
Many (larger) shops have enough trouble keeping up with the major revisions of .Net that are already coming out. This strategy might work for a platform that is not the predominant development platform worldwide, but for Microsoft (and many developers) it would be hell.
Backward compatibility is taken very seriously at Microsoft, especially where developers (the lifeblood of the company since Windows took off in the mid-90s) are concerned. Breaking changes have unknowable impact due to the scale of Windows, and latterly .Net, adoption. Would you want to be the guy who had to explain to Steve Ballmer why your cool fix in the new minor version of .Net broke the apps on which GE (say) run their business? There is immense effort put into making sure that legacy apps and devices will continue to run. Increasing the matrix of versions to be tested would inevitably lead to corners being cut, and we all know what happens next, right?
You can counterargue that nobody has to adopt the latest. But who here does not install Windows SPs as soon as they come out, to avoid the drip-drip of hotfixes for security issues? There is a natural inclination to want the latest, though that has to be balanced vs stability concerns.
.Net has gone a good way to removing DLL hell from the Windows developer lexicon, and to some degree decoupled developer platform progression from OS releases. I don't think the majority of Windows developers are in a hurry to see that change. Love them or hate them, Microsoft have gotten very good at managing large, infrequent releases of what is still the world's de facto desktop standard. It will be interesting to see how Google manage the same problem, as Android takes that spot in the mobile market over the next year or two.
It's my understanding that C#, though created by Microsoft, is a programming language that can be used or implemented for things other than .NET programming. For example, I could create a compiler for C# to target native x86 or other processors or even a JVM. Is my understanding incorrect? Does anyone know if C# is used for anything besides .NET?
C# is used for an experimental operating system called 'Singularity' which is written in the managed level from the ground up. An interesting project to watch!
Edit: Thanks Jörg W Mittag for his comment - Helios is actually a modified form of Singularity to support satellite kernels, to quote from the paper I am reading right now 'Helios is an operating system designed to simplify the task of writing, deploying and tuning applications for heterogenous platforms. Helios introduces satellite kernels, which export a single uniform set of OS abstractions across CPUs of disparate architectures and performance characteristics. Satellite Kernels allows developer to write applications against familiar operating system APIs and abstractions.'...interesting...
Hope this helps,
Best regards,
Tom.
You are correct that it can be used for other things. It's a language specification...you can compile it into anything you like if you take the time, but it'd be a tremendous effort.
I don't know of any other uses besides Mono as jrcs3 said, but hopefully Eric Lippert will chime in and give you a compiler point of view on C#
C# itself is a specification specified by the ECMA that "specifies the form and establishes the interpretation of programs written in the C# programming language." as is the CLR. The most popular implementation of these is currently provided by Microsoft, which is the C#.net that you know. C# and the CLR are open standards, meaning that anyone can implement them themselves, hence the formation of mono, a C# compiler for mac/linux. Compare this to java, who's only implementation is provided by sun. It's not an open standard, so you can't create your own implementations.
from wikipedia:
Mono "An open source, cross-platform, implementation of C# and the CLR that is binary compatible with Microsoft.NET"
DotGNU "is a part of the GNU Project that aims to provide a free software replacement for Microsoft's .NET Framework"
Dot Net Anywhere is a .net CIL interpreter for targeting embedded systems.
As far as I'm aware, all currently existing implementations of C# build to CIL and run in the .NET CLR or compatible environment, and the only alternative to the .NET CLR I am aware of is Mono.
In other words, all current versions of C# build to run in .NET or Mono.
.NET and Mono use the same 'binaries', so effectively all current C# compilers have only one target.
Another area of use is for iPhone app development (and I believe iPad now as well) via MonoTouch.
What is MonoTouch?
MonoTouch allows developers to create C# and .NET based applications that run on Apple's iPhone and Apple's iPod Touch devices, while taking advantage of the iPhone APIs and reusing both code and libraries that have been built for .NET, as well as existing skills.
Roughly speaking, it goes like this:
MonoTouch -> MonoDevelop/C# -> write an iPhone app -> compiled to native code -> iPhone app.
Relevant links:
MonoTouch
Writing your First IPhone application in C# using MonoTouch
Note that Unity 3D also allows "C# Scripts", and compiles to target Mac, Windows, Web, Wii and iPhone (and therefore iPad).
There are indeed tools to convert a .NET assembly to a standalone executable or library, so that you don't need your clients to have the .NET framework. This also further protects your code against reverse-engineering to some degree -- you can't use Reflector to see the .NET source on a native binary.
See Remotesoft Salamander .NET Protector, for instance.
But, that isn't strictly C# -> native; Salamander converts the MSIL to native code.
On the other hand, there is at least one academic project on making a C# -> native compiler using LLVM, called LLVM#.
You can compile a C# program on Mono. But that probably doesn't count.
Mono is an alternative implementation of the Common Language Infrastructure (CLI) that runs on Linux and various other operating systems. As mentioned in other places, both C# and the CLI are ECMA standards and can be implemented by anyone who cares to do so.
Rotor is another non .NET implementation.
You can use it on iPod apps if you use MonoTouch.
I learned windows programming using Visual C++, and the Win32 API. Nowadays, it seems most apps are being developed in .NET using C#. I understand that most of the time there isn't much performance difference between native code and managed code. So I'm wondering, if I were to start writing a new desktop app today, is there any reason (other than the fact that I'm more familiar with C++), that I might want to write it in non-managed C++ instead of .NET? Are there still some advantages to using C++ and native code? Or has that method been more-or-less replaced with .NET on the Windows platform?
Of course I know that people who are writing low-level device drivers and similar programs wouldn't do it in .NET. I'm asking with reference to typical client-facing apps that don't make direct hardware calls.
IMO the most important one for small downloadable applications is that native code does not need the .NET runtime. While broadband becomes more and more common not nearly everybody has it yet.
Some people may be disappointed to see that your 2 MB application actually requires another 20MB of framework download and a bothersome installation process to run. If they are not sure whether or not they really need your application in the first place, they might just delete it before even giving it a try and turn to a competing product.
Performance (certain situations, such as graphics)
Memory footprint (as Mancuso said)
Use of existing libraries
No need for a runtime
Finer control
To list a few.
However, you may also want to look at the question from the opposite angle to fairly evaluate which language to use.
Additionally, you could use C++/CLI to incorporate both native and .net code.
If your application needs to be able to run without an installation (i.e. if you can't or shouldn't do something like install the .NET framework), you can't count on .NET being on a windows machine (pre-Vista). Lots of utility applications can fall in this category.
I would recommend to write every desktop application in managed code. .NET/C# is a great platform to do so.
My reasons:
Performance penalty is negligible. Google for benchmarks if you don't take my word. What matters more is the code itself. You can write O(n^m) algorithms in C++ or .NET/C#. JIT engines are very mature these days.
Unmanaged C++ has major drawbacks when it comes to unit testing, mocking and refactoring. It's very cumbersome and inflexible. Reflection allows managed code to make such things very convenient.
Deployment is a small issue. However, creating a setup which checks for the necessary .NET preconditions and installs them automatically is a no-brainer.
Compilation is quicker, no linker! It even happens in the background when you edit the code.
.NET library support is way better and cleaner than STL, MFC and boost.
No header files and macros. They are just error prone.
Security! Good bye buffer overflows, bad pointers, uninitialized variables...
Exceptions. Clear exception hierarchy in .NET. C++ exceptions are messed up.
Memory footprint. But unless you're developing for a severely handicapped machine memory-wise, it really shouldn't be an issue for most applications.
If you can afford the dependency on the stack, go for .NET
Modern, elegant, powerful and as a result much quicker to develop for.
But realize that you chain your app to it - to the language and the framework, if you forsee a future where you may want to escape this, then better think twice.
Win32 is old and clunky, but it works on virtually any Windows version without extra dependencies, and your code can be in plain, portable, C/C++.
+1 for not having to require a .NET package/install on the target machine(s). This is still a big issue.
When all machines have mono or NET it won't be such a big deal.
Two things that I can think of.
Protection of intellectual property. It's infinitely harder for someone to reverse engineer an Unmanaged C++ app. Managed .Net or Java apps can be easily de-compiled this is not the case with Unmanaged C++.
Speed. C++ is closer to hardware and has a smaller memory footprint as the other comment mentioned. This is why most video games continue to be written in C++ and inline assembly.
.Net programs also have a support lifetime, where native do not really. Native will run for many years across different OS's without requiring updates.
.Net programs can be hosed by bad .Net configuration, native just keeps on running and is hardly effected by OS updates.
.Net programs startup slow and feel sluggish, native starts quick and runs quick.
.Net has to be coded for lowest common denominator (most distributed framework version), Native compiles all code into application - so use what you want.
Use Delphi for Native, not C++. .Net is partially based on Delphi RAD and Java backend.
Has anyone spent any time comparing the various Objective C bridges and associated Cocoa wrappers for Mono?
I want to port an existing C# application to run on OS X. Ideally I'd run the application on Mono, and build a native Cocoa UI for it.
I'm wondering which bridge would be the best choice.
In case it's useful to anyone, here are some links to bridges I've found so far:
CocoSharp - distributed with Mono on OS X - www.cocoa-sharp.com
Monobjc - better documentation than the others (in my opinion) - www.mono-project.com/CocoaSharp and www.monobjc.net
NObjective - (apparently) faster than the others - code.google.com/p/nobjective
MObjc / MCocoa - code.google.com/p/mobjc and code.google.com/p/mcocoa
ObjC# - www.mono-project.com/ObjCSharp
The Mono team have released a new bridge called MonoMac.
It's essentially the desktop version of the MonoTouch framework they produced for the iPhone.
Miguel announced the new bridge on his blog here: http://tirania.org/blog/archive/2010/Apr-19.html
Once MonoMac matures, I suspect that it will become the bridge people use.
I've been trying out Monobjc, NObjective and MObjc/MCocoa with F# lately and I will go with MObjc/MCocoa.
Monobjc is as you write best documented and packaged but compared to the other two very slow and does not "rethrow exceptions" from ObjC.
I believe that NObjective and MObjc/MCocoa are the only two that rethrow exceptions from ObjC and that's why I find them to be the only real alternatives.
As discussed here NObjective uses structs with inheritance which I find quite scary and made me finally choose MObjC/MCocoa.
(You might have a licence issue as well. Monobjc and NObjective is under LGPL, MObjc/MCocoa is under MIT ...)
I think that NObjective is the best choise coz it have automatic code generation for Objective-C wrappers that can be easily configured to regenerate wrappers for further versions of Mac OS.
OK, I'll ask: why would you want to do this? Cocoa's UI archtecture, including Cocoa-std delgates and Cocoa bindngs are closely tied to Objective-C. The combination of Interface Builder and Objective-C is remarkably productive. Although you can use Interface Builder with many bridges to Objective-C (including PyObjC, MacRuby, and many of the C# bridges), you will inevitably loose productivity due to any impedance mismatch between the framework and your language of choice. With C#, this mismatch is significant. Since you're writing a native UI, thus loosing any cross-platform advantage you would gain from C#, I would use Objective-C. For a competent C/C++/C#/Java/etc. programmer, it generally takes 2-3 days to become comfortable and productive in Objective-C.
A fairly lengthy discussion of the various bridges has taken place on the Mono-OSX mailing list.
The discussion starts here with Miguel:
Announcing that Cocoa# will no longer be maintained by Novell.
Attempting to unify the remaining efforts in the community.
If you read the rest of the discussion, it appears that the Mono community is leaning towards either Monoobjc or MObjc / MCocoa; so if you're doing your own investigations these are probably the ones to focus on.
Not going to ask why, since you have your reasons I am sure.
I would look at the Unity3D project and see if you can suss out how they did it. Looks, um, hard.