2

Hi I want to know why people develop library applications and employee management applications in C++ (this application, for example), when clearly the same thing can be done in C# and VB.NET in a much prettier way. Even banking applications are mostly in C++. Is there a good reason why, apart from the fact that compiled C++ code executes faster?

Can anyone shed some light on this?

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
Haxed
  • 2,887
  • 14
  • 47
  • 73
  • 9
    What one considers "pretty" is a fairly subjective judgement, don't you think? – stakx - no longer contributing Jan 22 '11 at 21:58
  • Portability and platform independence. – dalle Jan 22 '11 at 22:05
  • 2
    Good question actually. The OP has sufficiently restricted the question to specific domains so that it makes sense. – Konrad Rudolph Jan 22 '11 at 22:07
  • 3
    The linked project is ugly in terms of code, I don't think it should be taken as example of what a C++ application looks like. – Matteo Italia Jan 22 '11 at 22:08
  • BTW, employee record keeping should really be a web app, with back-end implemented in your language of choice (Perl+some web framework, JSPs/servlets, Python, whatever rocks your web development boat). THAT specific app has no business being a C++ app if it's being written these days (though it might be C++ if it's 20 years old and still working perfectly fine :) – DVK Jan 23 '11 at 03:05

6 Answers6

5

C: 1972

C++: 1979

C#: 2000

Now think of the lifetime of a library, especially in a bank, plus, you get to use the libraries (theoretically) on almost every computersystem in existence (as opposed to C#)

You will also still find a lot of COBOL (1960) there.

TToni
  • 9,145
  • 1
  • 28
  • 42
5

The main reasons for C++ for say banking applications is:

  1. Legacy code. A large financial firm typically has ~10-20-30 years of business specific C/C++ libraries developed in-house, plus a bunch of business specific vendor libraries which may not be available for C#

  2. A LOT of that financial code runs on Unix/Linux. While you can purely theoretically build C# code for Linux, it's definitely NOT an established technology you want to bet billion dollar amounts on.

DVK
  • 126,886
  • 32
  • 213
  • 327
  • Because those reasons barely scratch the surface, let alone being "main" reasons. The main reason is that C++ is particularly suitable for developing large-scale, complex, but at the same time efficient, software systems, and all of these qualities are requirements for banking applications. – HighCommander4 May 28 '12 at 06:45
  • @HighCommander4 - (1) OP explicitly stated "**apart from the fact that compiled C++ code executes faster**". (2) There are VERY few banking applications where C++'s raw efficiency is required. Most of the time the choke points are IO (network and file) and databases. Your app will be just as (in)efficient if written in C++, Java or Perl. And presumably, Java is better suited to large scale/complex (this is coming from someone who detests coding in Java, BTW) – DVK May 28 '12 at 13:17
4

C++ is usable on other types of systems, whereas c# and vb.net are not.

levis501
  • 4,117
  • 23
  • 25
  • 3
    Any system. Like anything you see around, embedded or not. – Klaim Jan 22 '11 at 21:59
  • 1
    @levis501: Not 100% true. You can use Mono to compile and run C# applications on a bunch of different platforms. Check the Wikipedia article: http://en.wikipedia.org/wiki/Mono_%28software%29 – Mike Bailey Jan 22 '11 at 22:03
  • @Sagekilla - is Mono a stable production ready system guaranteed not to cause a system running a couple of billion of dollars to crash? (genuine question, I don't know anything about Mono). I know I can trust gcc or VS2008 this way. – DVK Jan 22 '11 at 23:47
  • @DVK: I'm not sure. I've used it in the past to compile code for Linux, but I can't speak for how it's used in a production environment. I've only ever used it to run some personal projects in a Linux environment. Judging solely by the Wikipedia article though, it's been in development for over 6 years now. Sorry I can't comment further on that point. – Mike Bailey Jan 23 '11 at 00:39
  • @DVK: I also cannot answer directly on Mono's stability. (Looking at the source and seeing e.g. whether it has a comprehensive suite of unit tests etc. might give us a clue about that.) But I am fairly sure to assume that if some software fails, that's usually and foremost due to a bug in that particular software, and not because of a bug in some of its base components. That's *not* an eternal truth, but comes down to probability: Much more man-hours have gone into developing Mono (or similarly popular and widespread frameworks) than into any one single application. – stakx - no longer contributing Jan 23 '11 at 09:46
  • @stackx - the probability in question is not whether Mono has more bugs than a random app, but whether Mono has more bugs AND less features to catch app's bugs than "gcc+rational+entire c++ development stack". – DVK Jan 23 '11 at 11:56
2

Apart from technical reasons (such that C++ is an "unmanaged" language with quite different capabilities and properties than .NET languages), this can simply be due to preferences. Not all people find that C# and VB.NET are the best tool for every task. Or the prettiest. Why do you think so? And why should others not have similarly good reasons for choosing another tool of their liking?

Update, in reply to Konrad's comment:

It's correct that "preference" is indeed too narrow a term. There's other facets to it:

  • Managers / bosses can turn their (possibly badly informed) preferences into business policies;

  • A corporation's decade-old codebase can mean that when it comes to choosing the programming language for some new task, you'll evaluate languages with a different perspective. You want to or need to reuse the existing code, so interop with the old code's language must be possible.

stakx - no longer contributing
  • 83,039
  • 20
  • 168
  • 268
  • Preferences are one thing but I believe we can muster a host of *objective* reasons why C# and VB are more maintainable than C++ applications. No need to get exotic: the IDE experience and object orientation are *vastly* superior in .NET. – Konrad Rudolph Jan 22 '11 at 22:10
  • @Konrad, well said. I replied to your comment in my answer. – stakx - no longer contributing Jan 22 '11 at 22:18
  • Oh god, the IDE is probably *the* biggest reason to prefer C#/VB.NET over C++. The benefits you get from the language pale in comparison (at least from a developer's perspective) to the tediousness of working with Visual C++ and its broken Intellisense. +1 for an insightful answer. – Cody Gray - on strike Jan 23 '11 at 04:16
1

It might be a factor of the knowledge economy of a particular company. For example, the bigger a company gets, or the less staff turnover they have, the harder it will be to replace competence, process and tooling to accommodate, for example, a new language. C/C++ has been around for quite some time, and many developers as well as development shops have that background.

Concerning banking applications, the reason is, I would guess, mostly because you have a close to metal environment which allows you to utilise realtime programming in a dependable fashion.

awdz9nld
  • 1,663
  • 15
  • 26
  • realtime programming??? Unless you're running some frequency trading fancy shmancy stuff, there's absolutely no reason whatsoever to bother with anything so useless in a normal financial company. – DVK Jan 22 '11 at 23:54
0

Every language has its pros and cons and no one language is best for every application. Programs in C++are harder to write, but can take advantage of platform-specific hardware and features. Because they're compiled, they also tend to run a bit faster. C# programs are easier to write, but aren't able to access underlying resources and can't be ported to non-Windows platforms very easily.

In short, it really depends on the application needs. If you need raw speed and explicit resource management, go with C++. If you want ease of coding and clarity, go with C#.

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065