Is it C# Territory?

Your good reason is "We have hundreds of thousands of man hours invested in our giant aging C++ code base, thus we'll be keeping that around. kthxbye."

Yes, it could be used.

If you want to develop a brand new CAD application, feel free to use it.

I think most CAD software predates C#. And also predates Mono (which means they would have been non crossplatform).

Your good reason is "We have hundreds of thousands of man hours invested in our giant aging C++ code base, thus we'll be keeping that around. kthxbye."

Sunk cost fallacy...

A good reason would involve comparing the expected results of the new product against the quality of the existing product to see if the value of improvement exceeds the implementation cost and risks.

Your good reason is "We have hundreds of thousands of man hours invested in our giant aging C++ code base, thus we'll be keeping that around. kthxbye."

That, and "everyone here knows C++ so we're more comfortable using it".

Those two together answer 90% of "why did they use this language" questions.

Depends on the company, I think AutoDesk has some products that you can interop with C#. Others, like my company (e.g. https://www.bentley.com/en/products/brands/openroads) use a mix of C++ and C#...many of our power applications sit ontop of a C++ platform for graphics, element storage, etc but a lot of the business logic and UI are in C#.

C# is more than suitable for a robust graphics application however, you will need to care more about memory management than a typical C# programmer may (e.g., the upcoming language feature of "ref returns" is a big deal to us, but at the //BUILD conference this year it kind of just was shoehorned into the C# team's presentation).

Your good reason is "We have hundreds of thousands of man hours invested in our giant aging C++ code base, thus we'll be keeping that around. kthxbye."

Sunk cost fallacy...

A good reason would involve comparing the expected results of the new product against the quality of the existing product to see if the value of improvement exceeds the implementation cost and risks.

... and that cost would be hundreds of millions of dollars.

Your good reason is "We have hundreds of thousands of man hours invested in our giant aging C++ code base, thus we'll be keeping that around. kthxbye."

Sunk cost fallacy...

A good reason would involve comparing the expected results of the new product against the quality of the existing product to see if the value of improvement exceeds the implementation cost and risks.

Disagree with this application -- at some point its been far too long since the train left the station, the train's designer died or retired years ago (no one really knows), the conductor and engineering staff have completely turned over 5 times, and no one remembers any of the bugs that were squashed into the tracks further than about a mile back.

Its almost never a good idea to go all green-field over your existing product when the product is large and complex, and when your user-base is entrenched -- and especially when they're entrenched in your product's quirks and bugs. You want to talk about a nightmare... reaching feature-parity with a large and complex product is a nightmare -- but reaching bug-parity with the kinds of bugs people come to rely on (which, by definition, stayed around long enough to be relied upon precisely because no one could ever figure them out) is more than a nightmare, that's some Hellraiser shit right there. You know that weird for-scope bug from Visual C++ 6? The one with the option to turn it back on in every version of Visual C++ since it was fixed? There's a small set of regression tests somewhere in Microsoft that make sure no parser change or bug fix messes with that, and there's an engineer who's job includes making sure those regressions never go red. 20 years later that's still earning someone their bread, because the cost to the business is less than the cost of losing clients who can't or won't fix their code, even though its a good idea. And that's a trivial example.

Generally you would only make that kind of leap when the market forces your hand -- In recent years there's been a good deal of effort to get off of old systems written in COBOL and Fortran that very possibly run on old hardware you can't buy any more (and even repairing is difficult and costly), but mostly because there aren't any new COBOL and Fortran engineers who understand the intersection of those languages, and machines, and operating systems, and they can't persuade enough old coders to come out of retirement and into consulting -- the ones they can convince are A) billing at rates somewhere between a-charity-date-with-the-queen-of-England and who-wants-to-hunt-the-last-African-rhino, and B) are not unlikely to drift away at any moment due to death or dementia.

That sounds an awful lot like comparing the expected results of the new product against the quality of the existing product to see if the value of improvement exceeds the implementation cost and risks.

I'm going to get lots of hate for this, but here it goes.

First of all, I've been developing CG applications for a while now, and I have lots of experience with writing stable, performant code.

The main reason why people use c++ is very simple, it's the best language that allows us to organize our code nicely and write high performance applications. Right now it's the only choice (c and asm is performant as well, but they make organizing your code harder). Basically everything else is slower, and we are talking about an industry where even 5% matters a lot. A lot.

Of course you could write the core of your application in c++ (where you need performance and also memory management), and create the ui / user interaction code in c#, you are free to do that. But you have to weigh the extra boilerplate code neede dfor interop. Some people could say, it's worth it, some people won't.

But for the core, go with c++. At this moment there isn't a stable enough alternative. Rust looks like a worthy competitor, but it's not as mature as c++. (tooling, enough people on the job market, generated binaries not as optimized as they could be etc..)

Its almost never a good idea to go all green-field over your existing product when the product is large and complex, and when your user-base is entrenched -- and especially when they're entrenched in your product's quirks and bugs. You want to talk about a nightmare... reaching feature-parity with a large and complex product is a nightmare -- but reaching bug-parity with the kinds of bugs people come to rely on (which, by definition, stayed around long enough to be relied upon precisely because no one could ever figure them out) is more than a nightmare, that's some Hellraiser shit right there. You know that weird for-scope bug from Visual C++ 6? The one with the option to turn it back on in every version of Visual C++ since it was fixed? There's a small set of regression tests somewhere in Microsoft that make sure no parser change or bug fix messes with that, and there's an engineer who's job includes making sure those regressions never go red. 20 years later that's still earning someone their bread, because the cost to the business is less than the cost of losing clients who can't or won't fix their code, even though its a good idea. And that's a trivial example.

Indeed, the history of tech is littered with the corpses of companies that decided to rebuild their flagship product from the ground up.

Based on my experience, limitations of C#:

Majority of specialized 3rd party libraries such as graphics APIs and geometry processing are built using C/C++. Writing a wrapper is another project especially if the library is big and complex.

Managed languages don't give you control of memory allocation de-allocation policies; cannot build your own memory manager for most frequently allocated objects. Memory usage can explode very quickly if the application is heavy on objects and data structures.

Lack of on stack frame allocation/deallocation of local objects, or at least not guaranteed.

C# GUI is still behind something like Qt or even MFC, even if it looks easier to use.

Now what reason I would go with C# other than it makes average and entry level programmers life easier???!!!

I was almost in agreement until you mentioned MFC being better than 'C# GUI'. Do you mean Winforms or the various XAML flavors? (Yes, annoyingly WPF uses XAML, universal apps use XAML, but they don't have the same feature set) Though to be fair, I haven't kept up on MFC, I didn't even realize until today that they added DPI support.

Yes.

I'll be honset, it is not the best platform for real time software because:

- CLR + Garbage Collector does not go well with high performance issues. When they arise, they will be harder to solve by code. (Usually they just add memory and cpu to the machine because the heaps ate all the memory).

- Poor code: Not all C# programmers are excellent at writing fast realtime software. One wrong mistake with the GC and you eat a 1 second delay where you should not.

- Usually you'll want to go native, and native code with managed does not stack well. (Not as with just pure C code... which is probably what the native code was written with).

I'll say it again, there's a reason C++ is a standart for high performance application.

It's not the only choice, may not be the best for everything, but it is a damn standart.

So now we need to use Rust and D for future high-performance applications?

- Save time by going with C#

- Use saved time for pushing compute-heavy algorithms to GPU instead

This is exactly what is happening at my job currently (MRI scanner). Most of the user-facing code is moving from C++ to C#. More and more of the high-performance code is moving from C++ to CUDA and the likes.

- Save time by going with C#

- Use saved time for pushing compute-heavy algorithms to GPU instead

This is exactly what is happening at my job currently (MRI scanner). Most of the user-facing code is moving from C++ to C#. More and more of the high-performance code is moving from C++ to CUDA and the likes.

How would C# save my time? What about Java? Does it save time too? Python?

I may save some time and effort, but then I will hit the C# limitations I mentioned above!

Just use whatever you want. The language debate is rarely productive and mostly leads to people acting shitty to each other.

Removing a personal attack and a reply to the attack. Please remember to keep it civil and stay on topic.