Develop Reference

Is there an alternative to C# TPL Dataflow for C++?

I recently posted a question on Using Delegates to simulate connected objects where I received a great answer on using the TPL DataFlow library to very easily and cleanly develop a solution to my application.
The problem is that I am stuck on .NET 3.5 or under for C#. I thought I might have been able to upgrade to .NET 4.5 be I cannot at this stage. As far as I've been able to determine I cannot retarget the Dataflow library to .NET 3.5 so my next solution is to look for a C++ alternative under a similar vein to that of TPL Dataflow - Its not the best scenario but I can compile C++ code to a DLL and import it to our C# application.
To summarize my requirements for a C++ library for this question:
I need to be able to connect nodes together in complex networks and pass units of a resource between them. Some of them will produce finite amounts of resource over time. Others will consume it at a specific rate.

You might consider using mono's version of TPL Dataflow and compiling it yourself for .Net 3.5.
I think the biggest problem you'll encounter when trying to compile that code is that it relies heavily on TPL, which is not normally available for .Net 3.5. But it seems a backported version is available in older versions of Rx, so using that could work.
(Also, parts of the mono's version of TDF was written by me and I didn't receive pretty much any feedback about it, so it's quite certain there are bugs in there.)

Best programming language to convert a C# system to cross platform application?

I have done a lot of research regarding this issue. but i am still confused in choosing the right programming language. I wanted to convert my system which is programmed using C# to a cross platform system. Even though c# is an cross platform language the mono project is not successful according to my research.
Please give me your suggestions to this problem? I believe c++ and java will be an ideal programming language but java doesn't provide good GUI and if i choose c++ i will get stucked when converting my dll to c++.
Please provide your suggestions. Thank you.

Since Java syntax is a lot like C# syntax it would be easier to convert the code to Java. And there are actually some nice GUI libraries for Java.
See which-gui-library-is-the-best-in-java (Deleted in the meantime but Swing and SWT were favoured there)

I don't know what you mean by a good GUI, but you could use SWT which gives native integration to file/Open dialog boxes etc, rather than using the Java ones.
Of course a lot depends on how cross paltform you need it to be. Some devices only support C.

"cross platform" is not a fixed term. For example: Using the Eclipse RCP you have SWT on board. Your code uses the RCP stuff and would be platform neutral. But the embedded SWT libs would require either per-platform installable packages or one big package containing the SWT libs for all supported platform. If this is OK for you, you could use Java+SWT+(anything else you want) and have nice GUIs.

There is NO truly cross-platform language or technique. Yes, Java and Python can provide some abstraction over a platform... But everything stuck if only you add ":" to your file-name.
I mean, creating a software that is truly runs on many platform is FAR more than only choosing between Java, C# and C++. If one developed such software, one would understand me...
There is NO problems with Mono if you consider Mono as a target platform from the beginning. The most problems with mono happens when something is already written in .NET without ever aimed to be run on Mono. In this case there could be problems. If you bare in mind Mono from the beginning it is still the excellent platform.
As something that wasn't suggested here yet, I could refer you using python with Glide as cross-platform solution of creating applications with GUI.
Or you can see the Vala GObject system. Which syntax is really C# alike.

What advantages are there to developing a Win32 app in C++ over a .NET app in C#?

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.

Interaction between Java and C#

Is it possible to write a user interface in Java for an application written in C#?
I am working on a user interface of a project that is written in C#, but I have no experience with C# and I am an avid Java user. Is it possible to build the user interface in Java using Java's Swing and AWT libraries that operates an application primarily written in C#.
If this sounds like a really stupid question, I apologize in advance.

You might be able to leverage some of the interoperability features that are integrated into Mono 2.0
http://www.mono-project.com/Main_Page
JNBridge is another possible interoperability solution:
http://www.jnbridge.com/
However, a more optimal approach might be to expose your .NET code as Services - and then access them from the Java client (or through a light-weight ESB).
Of course, time, budget, resources are constraints you'll have to consider.

In addition to http://www.jnbridge.com (proprietary)
you can try http://www.janetdev.org, - open source implementation of a Java 5 SE JDK environment for the .NET platform. Currently it supports .Net 3.5 only (not Mono).

We did this recently and went the route of using a low level socket connection, but pushing xml through it. C# was the server side, and we used the Microsoft 'xsd' tool to generate the XSD schema for the objects and then used JAXB on the java side to generate java code to parse and hold the same objects.
As Barry mentions most of the work/problems was around the socket connection - but that depends on how comfortable you are with that.

Also, for a solution that cross-compiles your java to run in the CLR: http://www.ikvm.net/

I am author of jni4net, open source interprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.

Do you recommend Native C++ to C++\CLI shift? [duplicate]

This question already has answers here:
Is there any advantage to using C++/CLI over either standard C++ or C#?
(4 answers)
Closed 7 years ago.
I have been working as a native C++ programmer for last few years. Now we are starting a new project from the scratch. So what is your thoughts on shifting to C++\CLI at the cost of losing platform independent code. Are there are any special advantages that one can gain by shifting to C++\CLI?

I would recommend the following, based on my experience with C++, C# and .NET:
If you want to go the .NET way, use C#.
If you do not want .NET, use traditional C++.
If you have to bridge traditional C++ with .NET code, use C++/CLI. Works both with .NET calling C++ classes and C++ calling .NET classes.
I see no sense in just going to C++/CLI if you don't need it.

Some questions to consider before switching:
[1] Are you fine with sticking to Windows? There are .NET clones for other OS's, but your app is not going to just run transparently. A complexity you might not need.
[2] Are you considering switching just for the garbage collection support? If so, you can just use some C++ garbage collector libraries. And if you figure out how to leverage std::shared_ptr, you might not feel the need for garbage collectors. An overhead you might not need.
[3] Are you considering C++/CLI because of the garbage collection & all the useful .NET classes that you can leverage? If so, why not just switch to c#. C++/CLI is a transitional technology, and it is best not to invest resources in such things. c# is getting pretty mature and usable.
Personally, I would just stick with C++ ;).

Is there any benefit to you? You will likely lose the ablity to switch to another OS.

don't bother unless you're integrating with .NET apps. Certainly do not use STL/CLR as its performance is truly awful.
Its tempting to flip that switch to use the .NET class libraries, but there are alternatives. If you do this, you will not be able to port your code so easily.
It also seems that the rise of OSS is increasing, so now might be the time to investigate using cross-platform libraries and tools. You can deploy a linux app much more easily than a windows one (by shipping a fully-configured OS!), and you get much better ROI if you deploy linux clients (as they're free).
If I were a businessman, I would be looking to at least have the capability to deploy on linux or mac than just windows-only. Strategically, I would not want to bet that the world stayed with Microsoft in 5 years time.

The main advantage you would get moving to C++/CLI is to get access to the .NET libraries and the framework itself (garbage collection etc.). However, as far as I can tell the main reason C++/CLI exists is to ease the porting of existing C++ code to run in the .NET framework. New projects are encouraged to use C#.
If you need to use existing C++ code mixed in with the .NET framework, then it would make sense to use C++/CLI, but in general you should just begin with C#.
If there is something in .NET that the new project needs to use extensively (maybe simpler GUI design or something), then use C#. if not, then stick with native C++. I don't think you will lose anything by doing that.

I dislike C++/CLI so much that I'd recommend steering clear, as I describe here. Some suggest using C++/CLI as a bridge between standard C++ and C#, but thanks to the way C++/CLI is designed, it is very tedious to use that way (you have to manually create wrappers of normal C++ code that can be called from C#). Therefore, I would recommend SWIG instead for interfacing standard C++ with C# (although admittedly, SWIG has a substantial learning curve).

Take a look at those two articles:
A Critical Overview of C++/CLI, Part I
A Critical Overview of C++/CLI, Part II
I believe that by now you are
convinced as I am that C++/CLI is
neither a "set of extensions to C++"
(in many aspects it’s actually a
subset of C++), nor is it related to
C++ more than any other language with
semicolons and curly braces.
Furthermore, C++/CLI is definitely a
Windows-oriented programming language;
it’s definitely not a language that a
Solaris 10 server or a Nokia mobile
phone will be happy to run. What does
it have anything to do with C++?

One main disadvantage of using C++/CLR is the possibility of losing your IP (intellectual Property) if the code is not obscured suficently. In general I agree with the statements made by other members here. If you want portable code independant of the MS .net vm then native C/C++ is the way to go.