QuoteOriginally posted by: nocturne2Example of automatic memory management:Pure C++: boost::shared_ptr<StrikedTypePayoff> payoff(new PlainVanillaPayoff(type, strike));C++/CLI: StrikedTypePayoff payoff^ = gcnew PlainVanillaPayoff(type, strike);Now where did I see those classes? Just for completeness, you can add garbage collection to C++; googling for "garbage collector" and "C++" should turn out a few libraries. If you define an operator new() inside a class which allocates its memory by means of such a collector, just writingStrikedTypePayoff* payoff = new PlainVanillaPayoff(type, strike);will give you a pointer that will be collected once no longer used.Luigi

QuoteOriginally posted by: lballabioQuoteOriginally posted by: MikeCroweWhat about VB.net anyone? Its about as fast to code as Java, and runs as fast as C++, plus it can do anything C# can do and almost anything C++ can do. C++ may run quick... but developement is soooo slooowww....For real fast development you might want to use an interpreted language---Python, Ruby, Scheme, take your pick. Any of them is a winner for prototyping. Once you've done and debugged your prototype, you can translate it to a compiled language to gain speed (or you can keep it in the interpreted language if you find that most of the time is spent talking to the database anyway.)LuigiI am not a big fan of the "prototype in Python then translate to Java/C++/C# to gain speed" paradigm. Often times one can determine pretty accurately whether a compiled approach is necessary. Does the solution require huge matrix manipulations? Blazingly fast floating point calculations? Talking to databases? Writing terabytes into hard disks?With excellent platforms such as .NET and Java, one can prototype very fast, even with C++ (C++/CLI that is). I'd say at speed of 95% of Python. Java+Eclipse in particular is an amazingly productive environment (refactoring, quick fix, oh my!). The problem with the Python to C++ approach is overhead. Some one has to do the translation, and ideally it's the person who knows both Python and C++ well and worked on the original Python code, for otherwise there's lot of communication overhead. A person that good should be able to foresee if speed is critical or not. I tend to use Python for projects I know for a fact that speed is not an issue, and Java/C# when in doubt.

QuoteOriginally posted by: lballabioQuoteOriginally posted by: nocturne2Example of automatic memory management:Pure C++: boost::shared_ptr<StrikedTypePayoff> payoff(new PlainVanillaPayoff(type, strike));C++/CLI: StrikedTypePayoff payoff^ = gcnew PlainVanillaPayoff(type, strike);Now where did I see those classes? LuigiI know it would catch your attention, Luigi. Yes, it's straight out of your baby, Quantlib

QuoteOriginally posted by: madmaxI could be wrong, but my feeling is that Java generics are crap.why's that? I haven't seen them, but surely they fix the old problem with containers of objects and having to downcast?Tone.

QuoteOriginally posted by: ToneQuoteOriginally posted by: madmaxI could be wrong, but my feeling is that Java generics are crap.why's that? I haven't seen them, but surely they fix the old problem with containers of objects and having to downcast?Tone.C# versus Java generics versus C++ templatesThe Java implemenation is seriously handicapped due to backward compatibility.

QuoteOriginally posted by: ZmeiGorynychSo VB.net is not as unstable as VB 6 was?VB.net is hugely better than VB 6.0VB 6.0 was useless really for quant work, and I'd never advise using it, it had stability issues, was very slow running, and had poor implementation.Vb.net on the other hand runs just as quick as C++ when compiled, is very easy to code (easier than 6 even!) and is nice and robust. I'm a big fan of it at the moment, because the developement is so quick there's no real need to distinguish between prototyping and the real thing. You just go through after and tidy up. My only gripe at the moment is I have .net 2003 and that can't compile 64bit , but thats not a language issue...

QuoteOriginally posted by: lballabioQuoteOriginally posted by: nocturne2Example of automatic memory management:Pure C++: boost::shared_ptr<StrikedTypePayoff> payoff(new PlainVanillaPayoff(type, strike));C++/CLI: StrikedTypePayoff payoff^ = gcnew PlainVanillaPayoff(type, strike);Now where did I see those classes? Just for completeness, you can add garbage collection to C++; googling for "garbage collector" and "C++" should turn out a few libraries. If you define an operator new() inside a class which allocates its memory by means of such a collector, just writingStrikedTypePayoff* payoff = new PlainVanillaPayoff(type, strike);will give you a pointer that will be collected once no longer used.LuigiSo what you're saying is that one advantage of C++ is that it can act just like Java.

QuoteOriginally posted by: PaperCutQuoteOriginally posted by: lballabioJust for completeness, you can add garbage collection to C++So what you're saying is that one advantage of C++ is that it can act just like Java.Not exactly. One advantage of C++ is that it can act just like Java (or Python, or Ruby, or Scheme, or Common Lisp, or Scala, or [insert your favorite language]) if the programmer wants, and can act otherwise if the programmer doesn't. It puts the choice in the hands of the programmer. Ditto for the choice of paradigm (OO, functional or whatnot.) More choices give one more power to tailor the language to one's needs.Note that I'm not advocating C++ as such. If I'm advocating something at all, is that in an ideal world one should be able to use C++ for a given task, Haskell for another, Python for a third one, and even Java for yet another one if they are the best languages for the respective tasks. But if one---as it often happens---has to choose a single language, I'd rather go for one whose style can be adapted to my needs rather than one that forces my programs to adapt to its style.Luigi

Near-limitless flexibility is great in theory, but in practice it tends to lead to maddeningly obscure bugs and code that is a nightmare to maintain and re-use. It doesn't help that C++'s reputation as the language of choice for uber-geeks has cultivated a conventional "cool" coding style that tends towards the willfully convoluted and obscure.It is telling that some of the most useful and highly-regarded C++ books (Scott Meyers' "Effective C++" is a great example) devote a lot of space to discussion of how seemingly straightforward language features are actually deathtraps for the unwary. Most of the "limitations" in Java were put there deliberately by Gosling to make Java simpler, cleaner and less error-prone than C++. Read this section of the Sun "Java Language Environment" white paper if you want the details. As a developer and manager of developers, I think he definitely made the right choice. Since my current team spends most of its time on Windows client applications, I am eternally grateful that Microsoft decided to copy Java when they formulated the .NET languages.

At the end of the day, C++ (Meyers)is still the choice language for the top banks except for small groups that are doing something in a RAD environment. For FI the data loads are too great for the .net framework for positioning as the tech stands now. They are building parallel systems that will eventually be able to handle the hugh streams. The Problem with C++ is that many developers hae forgotten why they write certain code, they just know that they are supposed to write it like the book says.

Sorry about coming into this thread late, but the Great Debate continues. If you are a quant- or a quant-want-to-be, your focus should be in Finance, Financial Mathematics, and Software Development. The Software Development should be on adding value to the first two. Whatever the organization or whatever the legacy code or whatever the project goals are, the software developed should be of the highest quality (pass all testing scenarios), best performance (acceptable levels of user and business logic expectations), and be reusable (future projects).I know and have used C++, Java, and C#. Each is built on the foundation of the Object-Oriented paradigm, and thus issues of Encapsulation, Inheritance, and Polymorphism is more relevant to the discussion than which language is better. For a 1000 people that think Java is the best, I am sure we can find another 1000 that like C++ and another 1000 that like C# the best.Lets change focus to questions like "When modeling a portolio of assets where some assets (options and futures) rely on an underlying asset, what OO design pattern is best suited to model this?" If we need to maintain a historical record (i.e. snapshots of portfolio weights, P&L, etc.), what OO design pattern best allows to capture this and store efficiently in a relational database?

I agree with most of anamini's remarks, but the original question at the head of the thread was: "What do quants and traders see as the tradeoff of using C++ over other OO languages such as Java?" That's a topic that has generated a lot of heat in the past, but that doesn't mean it's not a reasonable question.My opinion, as a trader, developer and development manager, who has written production code in C++, Java and C# / VB.NET (which are pretty much "Java in Microsoft clothing"), is that the key pros and cons of C++ vs. Java-and-similar-languages are:Pros: big installed base of legacy code (at least in the finance / quant arena), maximum flexibilityCons: much more difficult to write robust, readable, maintainable, resuable code, particularly for newer or non-professional developersIn my opinion, the cons of C++ trump the pros for anyone who isn't "locked in" by the need to work directly with legacy code (i.e. modifying / adding to existing code, as opposed to just re-using existing libraries, which can usually be done from another language). It is certainly possible to write clean, clear, beautifully maintainable and reusable code in C++ - it's just a lot harder to do that it would be in Java, because the language and environment give you very little help. The problem is particularly acute for a semi-professional developer like your typical quant. It's kind of like trying to use a chainsaw to cut your food at the dinner table. It will definitely divide the steak, but it will probably also take a piece out of the table and maybe amputate your leg.

there are a few issues other than in which language is it easier to code. Context is important as well. Is the code in a latency sensitive environment? In that case if you need performance which is millisecond sensitive then the garbage collection in Java is going to cause you all sorts of outliers in your latency plot. No matter how carefully you code GC will at some time or another sneak up on you and take the VM from your control.If you're in a competitive environment- program / algorithmic/ stat-arb/ then your always going to be faster in C and C++. I can also tell you that this perfrormance gap will only widen in the next generation of Intel chips releasing this year.In most cases in our line of work the data access pattern is as much an issue as the coding pattern. Take a look at the way your application is calling data to be processed. There are a number of other ways to get data without introducing the hit from a relational db. As you can probably guess from the handle a lot of the work I do is in a distributed system (Grid if you must), we end up with thousands of nodes trying to get data from a single source, it wouldn't have mattered how efficient the code, if it didn't get the data at the node it couldn't process the data. At my last shop we brought in a distributed caching software to do this, effectively we run all of the nodes with a local cache which is an instance of the distributed caching software. This way the data gets to the node independent of any relational call, and therefore no data bottleneck. This had been great for a lot of the Java based risk stuff we had been working on, as the cache stores the data as java objects, we can then pull these graphs out of the "data fabric" when and where we need them. We end up using the database as a golden source for the data, but use the data fabric as the way that we access the data. The vendor also has c and xml native and you can C# or C++ using a wrapper (which does add a small extra step but tolerable).For the credit risk side and for the new program trading applications we are using another product (same vendor) but in this case they have a native C++ distributed cache. Not the most simple to use, but very fast. very low latency in getting data between 2 nodes (70 microseconds for a fix message on a 1GB backbone) we have to look after the serialisation and deserialisation, but they look after the HA, fail-over, mirroring etc) Throughput's not bad- we've seen about 400,000 objects (trades) per second. And again with the handle giving it away we're doing this on a one use only grid with over 200 nodes.Got away from the topic there sorry- As I said Java is as performant as C and C++ in most cases (can I suggest that you try JRocket as your VM or the new Sun 1.5) but if you absolutely need speed and stability then I suggest that you spen the additional time and build a C/ C++ production system.

To me, the difference is between tools that do what you tell them to do, and those where you ask it to do what it thinks is best.Something like SQL is very much towards to the "what you think is best", with C++ being far more towards the "why you are told".C# and Java are somewhere in between.This means that when you want to do something that is consistent with the plans of the language designer it can be highly effective.However if you want to do something different, it can get very painful very quickly.