Do you ever think of developing in other languages than C++?

[Zaphod (giancarlo)]

The stupidest thing on the planet, Google did it again and again in EACH library created. How many different debug printf around? They are even if conflict between themselves when you link different Google libraries at once.
There will be several hundreds smart pointers implementations around. Or black trees.
In java you have your standard bone, and it is highly optimized, and there is no wheel to create each time. It just works.
That hashset or the arraylist implementation ARE good and they have been ALWAYS good. You go on c++ and you never know what to do because the standard came late, you should adapt your old code again and again, syntax of things changed so many times and everything is a big mess.

It's getting there. You already have smart pointers int he standard, no need for new ones, threads are getting there (I hope C++14 will have more of these). ArrayList, I don't understand the issue with vector?
Syntax is constant, it doesn't change.

I will say something "strong" here, so don't take it personally, it is not my intention to offend you in any case: but I think you should try both languages for a while, maybe doing the same things in both of them in order to understand what I mean.
You "hope" c++14 will have. Java had waaaaay more complex things available and "standard". When you need a thread in java you have a single way for doing it. You don't invent the wheel again and again and again. If you need an hashmap, there is a single way, and it was a single way for doing it even 10 years ago.
The main issue I find in c++ is that most of things were unified just few years ago: when I started doing things in 2005 for acustica there was a crappy compiler on mac osx (xcode 3) and several crappy compiler on windows (I tried both borland, codegear, and microsoft) with a strange definition of "std" in all of them. Boost was still not an option, since was not supported properly in Borland. This complete lack of "standards" forced all programmers to "invent" the same wheel several times. I understand lately a standard is growing up in the c++ land, but it is a bit too late.

I repeat: each time I use code coming from google, facebook, me, microsoft, apple -> I find the same exact things rebuilt and rebuilt again and again and again using different sub-standards.

HOW MANY DIFFERENT STRING CLASS IMPLEMENTATIONS? Damn... strings.... the most SIMPLE thing you can think about. In 2005 even those damn stupid strings were not a standard. Borland had AnsiString. Microsoft used cstring. I don't remember the name for Apple, but I remember I wrote a compatibility layer for them. Oracle was translating his string class to std::string. Now, this f**king string class should be the most OBVIOUS thing I can think: go figure smart pointers!
Open source code coming from Doom3/id software or Oracle: the same things again, again , again!!!!

Maybe because a proper std was introduced in Microsoft compiler too late, and on the other side Apple modified this funny clang compiler too many times, leading to a complete lack of standard TODAY. Google itself is rewriting and rewriting the same things, and if you look at their code it is a COMPLETE MESS. It is a list of #define, unix things are loaded if it is not microsoft and viceversa hundreds and hundreds of times.

Now I understand this is perfectly normal for someone not used to java, but in java you have complex things available, standard and GOOD. Their hashSet implementation is GOOD, it was GOOD, and there is no reason for REWRITING it. Even its syntax is "coherent", and in line with all other patterns you find in the language. When you write java code everything is OBVIOUS, straight, SIMPLE. The day you need a concurrent hashset there is a different class but your code will still run perfectly without modifying anything else for the exception of the declaration. Maybe the most revolutionary improvement was the introduction of observers for this class... but you learn it once and you use it millions of times.....

[avasopht]

Vector is thread safe and thus slower because of the synchronisation cost.

You are talking about a different C++.. the one we talk about says:

Code: Select all

The behavior of a program is undefined if calls to standard library functions from different threads may
introduce a data race. The conditions under which this may occur are specified in 17.6.5.9. [
Note:
Modifying an object of a standard library type that is shared between threads risks undefined behavior unless objects of that type are explicitly specified as being sharable without data races or the user supplies a locking mechanism.
— end note

http://www.open-std.org/jtc1/sc22/wg21/ ... /n4296.pdf -section 17.6.4.1

In Java, not C++.

[avasopht]

You need as many String classes as you need. Can't say I've ever seen that causing any major issues on a project. And strings are far from trivial, Sun just came about at the right time and made them Unicode, plus it's inside a virtual machine. Google have their #define's for a reason, you don't have to if you don't need it. Being inside a VM affords you many luxuries but there is also a penalty.

C++ was standardized in 1998, and it's down to compiler vendors to support it. Some compilers allow non standard behavior but do offer standards compliant compilation. The first books I read on C++, such as Effective C++ were written during the standardization, so I guess I grew up with it

When I started out in the industry in 2007 I was using a pretty unique compiler (with an ISO compliant mode) and IDE that had its own reasons for being different, but I had no issue writing code that supported that compiler, MVC and GNU-C++. We had our own string class too, designed for our unique translation needs. If we were working in Java we'd have had to create our own string class too. Still, strings was never a big issue - never even noticed it and they were a primary asset.

I think FOCUS is key. If you focus on problems you'll have a problematic experience. I'm proficient and experienced in both C++ and Java and I work perfectly fine in both of them.

Java is certainly smoother, and having a GC with threading, etc. certainly makes some tasks easier. But the cost of all that coder simplicity is that there are things you can't do well, such as low-latency real time / embedded.

[ponce]

@Zaphod

This is in essence the argument for a "big" standard library.

Intuitively a language Standard Library would need only critical stuff like the STL. But this doesn't fare well because of the duplication you mentionned.

Now new languages tend to include everything in the standard library: HTTP servers, images, UI and for sure threads and semaphores are expected.

[Miles1981]

HOW MANY DIFFERENT STRING CLASS IMPLEMENTATIONS? Damn... strings.... the most SIMPLE thing you can think about. In 2005 even those damn stupid strings were not a standard. Borland had AnsiString. Microsoft used cstring. I don't remember the name for Apple, but I remember I wrote a compatibility layer for them. Oracle was translating his string class to std::string. Now, this f**king string class should be the most OBVIOUS thing I can think: go figure smart pointers!
Open source code coming from Doom3/id software or Oracle: the same things again, again , again!!!!

Are you kidding me? There is one official API, and that's it. You have different ABIs because you can implement them as you want, but if you stick to a runtime, no issue (just like you stick to the Oracle JVM).
And smart pointers are as easy as it gets. I understood them more than 10 years ago when they started out in Boost. If you have issues understanding memory management, I think that's where the issue with C++ is.
The standard library is fixed, whether it is Visual Studio, the different LLVM/CLANG flavors, gcc... and this has been the case for almost 20 years. Maybe that's because you used Borland at some point or C++ before the first real usable standard in 98?

[Zaphod (giancarlo)]

HOW MANY DIFFERENT STRING CLASS IMPLEMENTATIONS? Damn... strings.... the most SIMPLE thing you can think about. In 2005 even those damn stupid strings were not a standard. Borland had AnsiString. Microsoft used cstring. I don't remember the name for Apple, but I remember I wrote a compatibility layer for them. Oracle was translating his string class to std::string. Now, this f**king string class should be the most OBVIOUS thing I can think: go figure smart pointers!
Open source code coming from Doom3/id software or Oracle: the same things again, again , again!!!!

Are you kidding me? There is one official API, and that's it. You have different ABIs because you can implement them as you want, but if you stick to a runtime, no issue (just like you stick to the Oracle JVM).
And smart pointers are as easy as it gets. I understood them more than 10 years ago when they started out in Boost. If you have issues understanding memory management, I think that's where the issue with C++ is.
The standard library is fixed, whether it is Visual Studio, the different LLVM/CLANG flavors, gcc... and this has been the case for almost 20 years. Maybe that's because you used Borland at some point or C++ before the first real usable standard in 98?

you are taking it too on the personal level.
I'll try to explain it better, and I don't want to convince you.
I really don't have many issues understanding memory management. The fact that I implemented from the scratch smart pointers or even free-locking structures tells you enough about my skills, but this is out of topic. After 10+ years of c++ code, 12 hours a day it is perfectly normal I understand memory management.

Let's suppose that in 2005 there was a lot of confusion about the string class (just to name the simplest issue).

Consequence -> many ones implemented their version
Demonstrations -> most of libraries even today are based on strange wrappers and implementations

Other consequence -> complete lack of standard in older projects
Other consequence -> a lot of confusion TODAY. Projects are a mixed version of std:string, cstring or whatever classes were used for getting a stupid string. Database code is based on other implementations, Oracle code is just an example (I mean the database, not the vm).

We are not speaking about simple projects started few months ago. It is perfectly normal you use std::string. But for me it is not normal
1) my implementation is A LOT FASTER THAN std::string. It is heavily based on realloc techniques and it is very tiny. It means it can append strings at a very fast rate. My string is at least twice as much fast as std::string, because it tries to allocate more memory and to reuse it for being faster
2) this string class is so powerful that my XML implementation is rather fast too. I can scan a 100Kb document in few milliseconds. Normally XML readers are rather slow
3) I don't have any interest today for moving to std::string in my old projects
4) but they should be maintained. And I have a lot of issues today when I try to interface my class with other libraries, where a standard string implementation is expected

on the opposite

1) java had a f**king String class since the beginning. Slow? Fast? it doesn't not matter. It is a standard
2) nobody in java land created an other string class
3) yes for the exception of google (I mean protobuf). Those crazy guys.

I hope it clarifies

Now this String is just an example. Things are way worse on everything else, for example threads. Internet forums are crowded of people trying to get working those f**king threads on all platforms, invoking all possible implementations (pthreads, windows threads, boost threads). Look at Java: a stupid and VERY GOOD Thread class. Even a child can use it.


Now we are moving quickly to my point. What is the consequence of that?

1) c++ guys reinvented the wheel hundreds of time. I'm not joking, just look at facebook::thrift project. Compare it with google::protobuf. Do you see it? the same things reimplemented again and again and again
2) meanwhile java guys were focused on high level and elegant solution. They are focused on patterns. On objects. Everything is simply beautiful. Do you want a pool object allocator? simple, because you need few lines of code, and they rely on very standard objects. You don't ask to yourself which standard they are following. They are simply java. Ok there are differences, like lambdas, introduced recently. But most of code you find on the net just works EVERYWHERE
3) java guys can recycle MORE. They don't have issues linking libraries. You need an object which makes xxxx and yyy? just google a damn jar and you just ADD to your project and it will simply work
4) they can build very complex things easily
5) this is the reason why I'm so much fast there

[PurpleSunray]

Holy shit guys.. its a f*cking coding syntax.. no religion..

@Zaphod . you approach the problem from a different direction.
You have a high level requirement and want to find a lib that implements it.
Let take your thrift vs protobuf example: you want to a framework for service development and don't care about internals, so you go with the one from Java out of the box (or whatever you like).
Google on the other side has very different set of requirements, what also explains why there is Thrift, Protocol Buffers, Avro, .. its because there are NOT the same. They look same for you because you don't care about internals - if you care about, they are not the same anymore. Thrift uses an RPC stack, protbuff is handles it on the data model directly. Thrift uses exceptions, protbuff doesn't. Protobuf produces less traffic, but Thrift has more data structures ......

> java guys can recycle MORE
You can only recycle something if it still fits to the new requirements and that is all this discussion about.
For you a string is an object with a couple of manipulation methods. You do not care at all about the internals. But for the next one that string is a an array of bytes read from an mp3 ID3 tag.. which could be UTF8, ISO-8859, ISO-whaever, if it is <ID3 v2 you do not even know which codepage that string is encoded at ect.. If you assign such a blob to your call-do-all-string class, it can't do anything usefull with it.. you will need an ID3 string decoding... OMG yet another one?? common.... yes, yet another one, because this works different than the previews one.

So just stop that.. I do not believe that C++ codes reject to use STL just because they want to do it on their own. If you find custom string, map, set, .. classes on a C++ project, there is most likely a good reason why don't use the STL ones, so that is perfectly valid (in my opinion.. still sticking with the "right solution for the right problem, not one solution for all problems" paradigm..)

[avasopht]

Yes Zaphod, Java has a hardware abstraction layer so yes, there will be only one thread interface. That's the nature of running inside a VM, you're writing to a single platform.

I've had no trouble recycling C++ code, and there is plenty of "duplicated" Java code for the same reasons there are for C++. The first is that needs differ. The second is package management and the complications of depending on external code that you may need to synchronize updates with. Gradle and the like are a godsend.

Java most certainly helps you write higher level code and the fact it's running inside of a virtual machine comes with many perks. But I guess others don't share your bitter feelings towards C++, and it's got nothing to do with one's experience with Java, it's all about focus, perception and where you choose to place your attention.

[Miles1981]

I'm not taking it personally. I just see that you are comparing apples to oranges. If you required a fast XML parser in Java, you would implement it by hand as well. But in one way, what you say explains why C++ is faster than Java, even if you are saying the opposite (I don't believe that your parser is slower than the standard Java one?). And that's why you will always have fast real-time constrained code in such a language and not in Java (or any GC-based implementation of a language).

[Zaphod (giancarlo)]

Holy shit guys.. its a f*cking coding syntax.. no religion..

@Zaphod . you approach the problem from a different direction.
You have a high level requirement and want to find a lib that implements it.
Let take your thrift vs protobuf example: you want to a framework for service development and don't care about internals, so you go with the one from Java out of the box (or whatever you like).
Google on the other side has very different set of requirements, what also explains why there is Thrift, Protocol Buffers, Avro, .. its because there are NOT the same. They look same for you because you don't care about internals - if you care about, they are not the same anymore. Thrift uses an RPC stack, protbuff is handles it on the data model directly. Thrift uses exceptions, protbuff doesn't. Protobuf produces less traffic, but Thrift has more data structures ......

> java guys can recycle MORE
You can only recycle something if it still fits to the new requirements and that is all this discussion about.
For you a string is an object with a couple of manipulation methods. You do not care at all about the internals. But for the next one that string is a an array of bytes read from an mp3 ID3 tag.. which could be UTF8, ISO-8859, ISO-whaever, if it is <ID3 v2 you do not even know which codepage that string is encoded at ect.. If you assign such a blob to your call-do-all-string class, it can't do anything usefull with it.. you will need an ID3 string decoding... OMG yet another one?? common.... yes, yet another one, because this works different than the previews one.

So just stop that.. I do not believe that C++ codes reject to use STL just because they want to do it on their own. If you find custom string, map, set, .. classes on a C++ project, there is most likely a good reason why don't use the STL ones, so that is perfectly valid (in my opinion.. still sticking with the "right solution for the right problem, not one solution for all problems" paradigm..)

1) mostly likely reason: the lacking of a standard caused the cahos, in the name of the optimization. I'm not sure I'm correct, but even the juce library implemented it

2) yes I use thrift and protobuf for different reasons. Thrift because it is a standard in several project types I have (and it handles async communication/transport among different languages), protobuf because it is faster as a serialization protocol, especially in java. It comes handily when you move data structures in jni, for example.
In my previous text i was not saying protobuf or thrift are doing the same thing. I said they are IMPLEMENTED rewriting several base classes again and again. Most of companies writing c++ have been spending a lot of time for implementing several base elements. You don't believe me? Just look at several game engines. Most of "helpers" are about threads, events, mutexes, smart structures, tree and storage structures, sockets, memory managers, serialization and... Strings.

3) I never rejected stl. Simply several years ago it was not there. Borland did not implement it.

[Zaphod (giancarlo)]

I'm not taking it personally. I just see that you are comparing apples to oranges. If you required a fast XML parser in Java, you would implement it by hand as well. But in one way, what you say explains why C++ is faster than Java, even if you are saying the opposite (I don't believe that your parser is slower than the standard Java one?). And that's why you will always have fast real-time constrained code in such a language and not in Java (or any GC-based implementation of a language).

I never said c++ is slower than java, I told you it is at least 2/3 times faster.
The issue is not about cpu cycles, but about memory usage and real-time deadlines.


I said that simply with the same experience in both languages I can create things easier in java than in c++. What's wrong with that?

[dmbaer]

I have a question about C++11/14. I learned my initial OO skills using C++ and then never used that language thereafter, moving on to Delphi and then to Java.

Did C++ ever get something akin to Java's interfaces? That one feature is deeply elegant and makes Java considerably preferable to C++ IMO. There's much else in C++ that I was glad to escape from, primarily the lack of type safety and an overabundance of pointers everywhere you looked. But I really have not followed the evolution of the language. Who knows, maybe now I'd fall in love with today's version.

I hope this is a joke? C++ is type safe, you can't mess up since C++03 except if you did it on purpose!

Not in the least a joke. I last worked with C++ in the early 90s and have not followed its evolution since that time. I do hope the claim for C++ type safety is true, for the sake of all C++ programmers. I've worked with probably a dozen languages over my 45 year career. I never found a language that gave me more holes-in-one (programs where the code totally works the first time you test it) than first with Delphi (object Pascal) and later Java. Rigorous type safety enforcement is much of the reason (and not requiring the use of pointers is another ).

A number of responses to my question suggested that multiple inheritance was the equivalent of Java interfaces. I would argue that is not so, unless something has happened to C++ on this front. Twenty-five years ago, *many* C++ luminaries gave poor marks to the use of multiple inheritance. Mix-in classes (is that term still in use?) were regarded as acceptable, though, and they do serve somewhat the same purpose. But they are still not nearly as elegant as Java interfaces, IMO.

[dmbaer]

Absolutely.
You cannot create audio plugins in java... yet. First of all there is the memory footprint, than java is at least twice slower than c++. Anyway computers today are running java faster than c++ 10 years ago. So for old techniques java is "usable" but still not perfect. You could experience dropouts even on very fast computers for simple tasks. It is a pity, because it is sooooo relaxing

You might be interested in this.

http://www.softsynth.com/jsyn/

I just discovered that this library exists. It's of no use for integrating functionality into a DAW, of course, but it might be fun just to play around with. But I have had the opportunity to check it out at all yet.

[Zaphod (giancarlo)]

Absolutely.
You cannot create audio plugins in java... yet. First of all there is the memory footprint, than java is at least twice slower than c++. Anyway computers today are running java faster than c++ 10 years ago. So for old techniques java is "usable" but still not perfect. You could experience dropouts even on very fast computers for simple tasks. It is a pity, because it is sooooo relaxing

You might be interested in this.

http://www.softsynth.com/jsyn/

I just discovered that this library exists. It's of no use for integrating functionality into a DAW, of course, but it might be fun just to play around with. But I have had the opportunity to check it out at all yet.

ah yes I'm aware about it. But I need all the speedness of assembly and c++ for doing what I'm doing now.... at the cost of a slower development....

[stratum]

After about 20 years of programming with c++, the only language I've liked in addition to c++ was erlang, and they have almost nothing in common. (and no, it's not suitable for low latency audio signal processing but my real job has never been that, unfortunately.).