"C++ Sucks" - Why?

[1yR4jE8b]

Lisp

[DeXecipher]

C++ only sucks for programmers *cough* code_monkey/scripters and people who are too lazy or get easily sidetracked by all of its power, excess of feature. C++ is about giving the programmer as much ability as possible without writing too much architecture specific code. AI is done in c++/lisp Embedded Systems are done in C/C++. NASA writes things in C/C++.

Linus Torvalds was a python programmer from my understanding, according to wikipedia. In short people like simpler languages because they allow them to get straight to the point without getting caught of into the features. I watched a lecture on youtube that explained the paradox of too much choice. Having an abundance of choice was deemed a bit paralyzing according to the lecturer. Having said choice more often leads to a better outcome but less happiness due to the loss of the resources, usually time and or money. The reason people use scripting languages is because are not necessarily that they are easier to use or to learn but its that they are faster to learn ALL of. If you add the fact that C++ is a super set of C (almost every feature of C is in C++) and you add people who have little time and or patience then have calamity.

The reason why OOP/scripting languages were invented was to more easily utilize the tools written in C and Assembly by simplifying or abstracting them. Python Java and C++ all come with precompiled/linked libraries written in native object code produced by an assembly language (more tedious to write). Python is implemented in pure C which is then converted into assembly code.

[hamsterman]

@DeXecipher, I agree with everything you said, except your point :D.

[3hM2Nwbp]

Cheraphy wrote:

If you really need to use Java for the bulk of your project then there are ways to tie your native code into it. (read: JNA and JNI)

I feel the need to insert another disclaimer here.

To anyone thinking about using JNA / JNI:

The native interfaces are a very often a royal pain to maintain (must maintain builds for all platforms and all flavors of the JVMs that run on each platform - that means at least X builds for each supported platform which must be either distributed correctly or otherwise provided correctly if your distribution is a web applet. Please only use it as a last resort (IE deadline is tomorrow and your ass is on the line). Granted there are rare valid uses for it, but most often it's a big mistake. (Think of what would happen if the user updates their JVM from 32 to 64 bit!)

Hopefully that will save someone one day.

[tition]

Linus Torvalds was a python programmer from my understanding

...cough cough...

[BHX]

All I can say is, if you think C++ sucks for OOP, try java. C++ eases you into OOP while Java from the onset drops the whole OOP boulder right on your lap. I would love to learn C, C++, C#, Java, Javascript, Haskell, Python, Ruby, and Assembly (asm just for the heck of it). Though, realistically, I doubt at 31 years old I could learn that many languages.

[naraku9333]

Though, realistically, I doubt at 31 years old I could learn that many languages.

I hope you're wrong there, I didn't even start learning C++ until I was 32. I'm 36 now and have done some C# and java though I wouldn't consider myself proficient in either. I do plan to learn them better and pick up a few more, in particular python. So if a 31 year old can't do it, I guess I'm screwed.

[BHX]

I hope I'm wrong too since I want to learn 8 languages :(.

[rapidcoder]

I can't remember how to do it in Java

Why JNI/JNA? You can do it in pure Java. There are at least two ways to do manual memory management without GC in Java:
1. mmapped I/O
2. ByteBuffer.allocateDirect

Besides that, GC is cheaper than general-purpose new/delete. It provides faster allocation and zero-cost deallocation for most of the objects - which is close in performance to a dedicated hand-tuned memory allocation in C++, implemented using placement new. That's why wide string manipulation in Java is faster than C++ std::wstring (which does quite a lot of allocations internally - whenever you copy / splt / append strings, etc.).

The native interfaces are a very often a royal pain to maintain

True, but this is not because of the interface, but because of the fact that native code is native. The exactly same restrictions apply to any C/C++ produced binary program or library.

[3hM2Nwbp]

rapidcoder wrote:

Why JNI/JNA? You can do it in pure Java.

Under the hood it's still achieved using native code. Using terms like "pure java" is very misleading... I am curious though, as to how this memory is deallocated...my guess would be phantom reference queues...but now I'm looking it up in the JDK source. * Looks like it's achieved by the sun.misc.Unsafe and sun.misc.Cleaner that are used in a private runnable class in DirectByteBuffer. Sun.misc.Cleaner extends PhantomReference, so I'm assuming that my guess was correct.

rapidcoder wrote:

True, but this is not because of the interface, but because of the fact that native code is native

It's mostly because of the fact that you cannot control which JVM the client uses after they install your application. Setting up a build chain for the different systems is pretty easy to do, but keeping the user from breaking the application is borderline impossible. An entirely native distribution doesn't suffer from this problem, as it will continue to run so long as the user doesn't muck around with the installation. That's why I blame the nightmare on the interface itself, as something as simple as a VM update can break applications that use JNA / JNI.

[rapidcoder]

Under the hood it's still achieved using native code

Right, but it is portable and you don't have to deliver any extra so/dll.

An entirely native distribution doesn't suffer from this problem, as it will continue to run so long as the user doesn't muck around with the installation.

Unless you link everything statically, there may be thousands of reasons native application breaks on the client system. E.g. wrong versions of / lacking / broken libraries or different kernel version, etc. As for JVM incompatibilities, I haven't seen any JVM that would use a different JNI API than the reference Oracle VM. So the only thing you have to assure is compiling your native library for the target OS.

[3hM2Nwbp]

rapidcoder wrote:

So the only thing you have to assure is compiling your native library for the target OS.

...are you forgetting that 32 bit libraries do not work with 64 bit virtual machines? I can only speculate that there are other varying factors that will also break outside of the native code such as using a non-oracle JVM.

It seems quite brain-dead to me that 64 bit VMs aren't compatible with 32 bit libraries. Perhaps the designers just cobbled something up like they did with type erasure designed it that way on purpose.

[rapidcoder]

Most 32-bit programs are not compatible with 64-bit OSes, so what?
You just release a 32-bit and 64-bit versions, just like with any other native program.

[3hM2Nwbp]

rapidcoder wrote:

Most 32-bit programs are not compatible with 64-bit OSes

Really? All of my old 32 bit native applications still seemed to work just fine after moving to a 64 bit OS.

rapidcoder wrote:

so what? (taken out of context, I know)

The point being: See the message 11 posts up. JNA / JNI in casual code: don't do it.

[ResidentBiscuit]

Generally a 32 bit program should work fine on a 64 bit OS/CPU, but not the other way around, obviously.

[naraku9333]

I don't believe that's necessarily true, 32 bit windows apps work because of WoW64 (windows on windows 64).

[rapidcoder]

Generally a 32 bit program can run fine on a 64 bit OS, as long as the system provides full set of required 32-bit libraries. On Windows that may be true, but on Linux it is not always the case. E.g. neither Firefox nor Chrome work seamlessly in 32-bits on Ubuntu.

JNA / JNI in a perfectly valid solution, but only for those who know what they are doing.

[Cheraphy]

E.g. neither Firefox nor Chrome work seamlessly in 32-bits on Ubuntu.

Did you mean 64-bit Ubuntu? If so I'd like to share my anecdotal evidence of having the exact opposite experience.

[chrisname]

Last time I used Arch Linux x86-64, it was almost impossible to get some 32-bit programs running. I've only used the i686 version since then.

[Cheraphy]

Maybe something I routinely installed after a fresh install also installed a buck-ton of 32bit libraries. O: