when to usee c++ over java?

[ckide]

when to use c++ over java?

[Moschops]

Definitely when the target system has a C++ compiler but no Java support.

[ckide]

thank you Moschops,
ok
database program for a school small and big, which i use c++ or java?

[Schol-R-LEA]

Which are you more familiar with, and do you have a C++ library for the database engine? Java has standard library support for database work in general (the standard C++ library doesn't have any), but still often needs driver for the specific DBMS. In most cases, the differences in support are negligible. Thus, it becomes (as usual) a matter of 'which do you like better?' and 'what does The Mgt want you to use?'

OTOH, if I could choose, I ditch both in favor of Python.

Oh, all right, what I'd really want to use is some Lisp dialect like Clojure. But what company would allow that? Maybe I'll actually get somewhere once I finish implementing Thelema, but I'm not going to hold my breath.

[DeanMSands3]

How are you at remembering to garbage collect and release unnecessary resources? You'll build the application faster in Java. You'll run the application faster in C++. That's been argument for years. Pick one.

[Moschops]

But now that C++11 has some nice shared pointers and associated gubbins, you've got the choice in C++.

[ckide]

   ...........  

[rubberman]

I've always considered Java to be C++ with training wheels, garbage collection notwithstanding. As a matter of fact, Java's garbage collection (gc) is a major contributor to performance issues for Java applications that are long-running and serious resource users. I wrote a reference-counting gc for C++ back in the 1990's that allowed us to run major enterprise applications written in C++ 24x365 with no memory leaks, and NO application-level delete calls! That code is still running most semiconductor, LCD display, and disc drive manufacturing plants today. These are plants where 1 hour of downtime costs about $10M USD in lost profits...

Smart pointers are fine, but unless they are combined with reference-counting life-cycle management, are of limited use. I'm not that familiar with C++11's shared pointers, so it looks like I have some additional research to do. :-)

[mike_2000_17]

Smart pointers are fine, but unless they are combined with reference-counting life-cycle management, are of limited use. I'm not that familiar with C++11's shared pointers, so it looks like I have some additional research to do. :-)

Yeah, you probably should. ;) Shared-pointers (shared_ptr / weak_ptr) are surprisingly robust and dependable. They are indeed reference-counted pointers. Moreover, the reference-counting is thread-safe (via atomic operations). As far as I'm concerned, it renders any other kind of reference-counting scheme deprecated, i.e., there's just no need, if you were to write a completely new library or application, to create another reference-counting scheme. And when you account for all the situations when unique ownership is appropriate (e.g., RAII-style data members or base-class, or unique_ptr pointers), and all the situations when shared ownership is needed (which are rare, actually), there is very little left (or none?) that would justify a full-blown garbage collector (i.e., 99.9% of the time, using a garbage collector is like killing a fly with a sledgehammer).

Also, the proof is in the pudding. Most of the fairly serious libraries that I have ever looked at generally use either an intrusive reference-counting scheme (for older libraries, mostly), or they rely on shared_ptr (or a similar variant, such as QSharedPointer in Qt, or IntrusiveRefCntPtr in LLVM), or, they don't really use shared ownership at all (and often, you don't have to, because software often naturally writes itself without it). Garbage collector libraries for C++ have been available for decades, but I have never seen or heard of a serious C++ library that uses one. That's because the situations when you need it, when unique or shared ownership is not sufficient, are almost non-existent. I've heard Herb Sutter casually and briefly refer to one very specific case where a garbage collector is "needed", but that's about it.

I wrote a reference-counting gc for C++ back in the 1990's that allowed us to run major enterprise applications written in C++ 24x365 with no memory leaks

Did it have non-deterministic destructor calls? To clarify, deterministic, in this context, means the destructor (and deallocation) is called immediately as the reference count goes to zero. If it is like that, then I would not call it a garbage collector, because there is no "background" collection going on (which would imply non-deterministic destruction of objects). If it's deterministic, then it's just a reference-counting scheme (centralized or not). Centralizing the reference-counting could allow you to break cycles (which you can generally avoid with weak_ptr), but otherwise, it's not needed.

Many people, including myself from time to time, have also pointed out that if you give up determinism in the destruction of objects, you largely have to give up RAII (automatic scope-based resource management), which will create far more complications in your code (manual clean-up code everywhere) than what you gain from the "care-free" environment that a non-deterministic GC gives you. Long story short, I wouldn't want a garbage collector even if it was offered for free (no performance penalty). There are lots of complications in Java code that are due solely to the existence of the non-deterministic garbage collector, making the C++ equivalent much simpler (safer and better behaved) in many cases. Seeing all the manual resource clean up that people have to do in Java, it makes me cringe, and makes me very happy that I don't have this bane on my C++ coding tasks. And, on top of that, Java programmers have to pay this heavy tax for having that useless monstrosity (GC) watching over everything they do.

How are you at remembering to garbage collect and release unnecessary resources?

That's an odd question. You seem to imply that if you don't want the trouble of manually releasing resources, you should pick Java, right? Wrong. Besides memory, in Java, you have to remember to manually release every resource you acquire (e.g., file handles, locks, sockets, streams, libraries, etc.), and that can add up to a heavy, error-prone burden on development. And also, in C++, you attach the life-time of the resources you acquire to the life-time of the code that uses that resource (through RAII classes), and therefore, you almost never have to remember to manually release resources because as execution leaves the section of code that uses the resource, the resource is released immediately, and with no fuss. I virtually never write code to manually release resources (memory or otherwise) in C++. So, to me, my answer to your question is "I don't trust myself enough on remembering to release unnecessary resources, and therefore, I prefer C++ to any garbage-collected language".

You'll build the application faster in Java. You'll run the application faster in C++. That's been argument for years. Pick one.

No. That has not been the classic argument. The classic argument is this:

If you need a high level of run-time flexibility (e.g., dynamic types, dynamic dispatching, run-time reflection, run-time type introspection, etc.), then you should prefer Java.

If you need a high level of static analysis (e.g., optimizations), robust behavioral guarantees (e.g., determinism, latency, etc.), compact data structures (e.g., better use of cache), and minimal run-time overhead (in fact, C++ is zero-overhead by default, everything is "opt-in"), then you should prefer C++.

That's the classic argument. The reason that Java has a garbage collector is a consequence of the design choice that I just mentioned (high dynamism) because it's safer that way and you are already paying for so much overhead that a garbage collector doesn't seem like such a big burden in comparison. The reason that writing applications in Java might be faster is because dynamic languages are, in general, faster in development time. This is due to a myriad of reasons, mainly that everything is more "flexible" by default (which comes at a price, of course), as opposed to a language like C++, where you have to opt-in to each piece of flexibility you want to use.

And, if all you are interested in is speed of development, then there are, IMHO, more appropriate languages, most notably, Python. In my opinion, Java is a dynamic language that tries to masquerade as a general-purpose (or even "system") programming language. Python is more honest in that regard, it's a dynamic language that doesn't pretend to be anything else and that makes it more appropriately designed for (or focused on) what it needs to do: provide an easy way to put together dynamic and modular blocks of code to create an application.

database program for a school small and big, which i use c++ or java?

That's pretty light-weight stuff. Java or Python are probably more appropriate for this. It's gonna be faster and easier. There are also good database connection libraries (although C++ libraries for databases are also pretty nice, and very often, exactly the same ones (Java or Python mostly uses C/C++ libraries wrapped-up under-the-hood)).

[rubberman]

@Mike2K
Yes, my GC was deterministic. It also dealt with circular references. I have made a serious study of GC methods in the past. It is a subject I am "somewhat" familiar with. :-) However, I understand your point that being deterministic it isn't "garbage collection" in a classical sense, but I would argue the point with you if we ever have a face-to-face... Current versions of PHP use a deterministic reference-counted GC - at least they call it a GC. You say tomato, I say tomato (with a softer 'a'). Still the same fruit. Of course, now we can argue whether a tomato is a fruit or vegetable! ;-)

[mike_2000_17]

Yes, my GC was deterministic. It also dealt with circular references.

Yup. That's exactly what I suspected. ;) I would have been very surprised to find out that you used a non-deterministic GC in high-reliability software like that. And given that the only reason to have a centralized reference-counting scheme is to handle cycles, it was a very good guess that this kind of "GC" was what you referred to.

To me, a garbage collector needs to involve "garbage" and "collection". The former being objects that are not yet deleted, but no longer used, i.e., discarded items. The latter being some sort of background process that, once in a while, goes through all those discarded objects and deletes them. A deterministic reference-counted scheme does not follow that definition, in my book, because it lacks both. As soon as an item is discarded, it is deleted, meaning that it never lingers as "garbage". And if there is no garbage, there is nothing to "collect". Even wikipedia (as the voice of the majority, sort of) is a bit ambiguous on whether pure reference-counting could really be considered as garbage collection. It loosely seems to consider that the terms garbage collector really only refers to uses of algorithms like semi-space collector, mark-and-sweep, or mark-and-don't-sweep, which are techniques that would definitely fit my definition of garbage collection.

By the way, the latest C++ standard also allows for conservative garbage collection. How it makes it possible has to do with some technical things that I haven't really looked into. But, technically, it would now be possible to implement native (non-library) garbage collection for C++. I don't think anyone has cared to do so yet though (and maybe nobody ever will).

Current versions of PHP use a deterministic reference-counted GC - at least they call it a GC.

Apparently, Python also uses the same scheme. BTW, wikipedia says "but not Perl 5, or PHP, which use reference counting", when referring to languages that use garbage collection. ;)

BTW, tomatoes are vegetables!

[sDJh]

Java has the benefit of being multi-platform too. You can compile it once and run it on pretty all major operating systems.

If you plan a software from scratch and can avoid system specific things like kernel-calls, than you'd be safe with C++ as well. You just have to compile it for each target platform and distribute different binaries.

[NathanOliver]

Yes Java is multi-platform but that can misleading as well. Different java runtimes can produce different behavior. If you use something from a newer version of Java it might not work on some machines running an older runtime. I ran into this in my Java class.

[jwenting]

database program for a school small and big, which i use c++ or java?

what your teacher tells you to use.

[jwenting]

If you use something from a newer version of Java it might not work on some machines running an older runtime. I ran into this in my Java class.

which has nothing at all to do with being multi platform or not, but with forwards compatibility.
It's like saying you're surprised that your C++ program compiled against Windows 8 and using Windows 8 specific API calls doesn't run on Windows 3.0.

[invadev]

Based on my exprience on my previous job, we used C++ to communicate with the hardware for instance dialogic/digital board which some of their APIs are avaible in C/C++. Then use JNI to interface with code written in other languages like C/C++.