C++ is still the best choice

Are most criticisms of C++ thinly veiled, "it's too hard for me" excuses? All my profs speak highly of C++ and emphasize the importance of learning it to make high performance applications. Stack Overflow seems to like it as well.

Why does 4chan hate it so?

>>1

People wouldn't liek seeples so much if it wasn't so popular. If you learn seeples and few other languages that are adequate replacements, you'll begin to identify places where it falls short. It has some nice things, but it's an ugly beast, and it could certainly be better.

>>2

>adequate replacements

I'd like to hear this.

>>3
much to learn, you have.

>>3
Lisp.

Are most criticisms of C++ thinly veiled, "it's too hard for me" excuses?
You haven't read C++ FQA Lite. http://yosefk.com/c++fqa/

>>3
Haskell. Erlang. D.

C99 is still the best choice.

>>7
>D
you best be trollin

>>7
Haskell
Has GC, compiler produces less efficient code than good C++ compiler. Too slow for speed critical applications.
Erlang
GC again. I don't know how good the native code compiler for this is, but I would guess it won't produce as good code as C++ compilers do.
D
This would be good. But it has GC. It can be disabled, but then the standard library becomes useless.

Just use C++.

HOW ABOUT PASKAL?!!?!

>>11
U MENA HASKAL!

>>1 Piss off sepples boy. /prog/ is for smug lisp wienies, haskell autists and suave spacetoads.

Just wait a year or two and Go will become the best higher level language. Even now, when it's in a rapid development pre-release state, its executables are smaller than statically compiled C++, it compiles way faster than C++, you need to write less code for the same program, has GC, has easy to use concurrency and multithreading, better compile error messages, better syntax and semantics, is about Java fast (and it will get faster), ...

>>14
has GC

that's a bad thing

>>15
Your face is a bad thing.

>>16
ure mooma's a gc

if it has a gc, it's bad

it's one of the ten commandments

>>18
Nobody gives a damn.

>>14
It lacks parametric polymorphism and exceptions, and it has null pointer. In 2012. And it was designed in 2008. It was the case that 10~20 years ago there was a global mental retardation of most programming language designers, but today we should know better. Go made several step backwards in PL design, we should point forward.

>>14
Go is shit. Algol 68 is far more advanced than Go (and C). Algol has garbage collection, anonymous functions (which are just proc variables), and no distinction between statement and expression. Any object can be declared in local storage or on the heap. It allows spaces and non-English characters in variable names, and supports multiple alternate forms including bold keywords, capitalized keywords, ASCII symbols, and APL-like mathematical symbols, but is still able to work with 6-bit character sets (after all, it was designed over 40 years ago). Variables do not need forward declarations. Algol 68 has par clauses and sema semaphores for parallel computing and synchronization. It has call by value, call by reference, call by name, and thunks, which are lazily evaluated expressions passed as arguments. Functions can return multiple values, which can be inserted into the argument list of another function (like Perl). There are optional extensions like "partial parametrisation" which allows partial parameters to be bound to values (currying).

>>21
Algol 68 has par clauses and sema semaphores for parallel computing and synchronization.
This.

too bad Algol's syntax is shit

Go is a fucking piece of crap, it will never go anywhere (pun not intended).

Anyone tried Ogle? I heard it was pretty good.

>>25
As in Go Ogle by Google? That's absolute genius!

>>21

Algol seems amazing. Is it used nowadays? Are there compilers for Unix?

>>27
I saw some foolholio at Stanford implement an Algol to COBOL...wait... I can't even finish it because the nature of the work was so wrong.

>>27
http://algol68.sourceforge.net/

It's good cause its just C except with optional objects.  And C is good because it's close to assembler so it lets you do things how you want them to do it efficiently and straightforwardly.  In other words, it expresses and reflects the machine's capabilities well.  With other higher level and more abstract languages such as Java and logical/functional programming languages, the languages often allow the programmer to specify "what needs to be done" rather than "how you do it".  For many applications, the "what needs to be done" model simply does not work or is too slow.  For example, writing a real-time operating system.  This is why C/C++ is popular.  You need real-time operating systems everywhere and your only choice is C/c++ or assembler, anything else, and there is not enough control or it does not reflect the capabilities of the hardware well enough. Personally I would prefer C/C++ rather than assembler.

>>30
it lets you do things how you want them to do it efficiently and straightforwardly.
When compilers can't.

For many applications, the "what needs to be done" model simply does not work or is too slow.
They're quite a few, but it's totally relevant to write significant portions of them as “close to the metal” as possible.

This is why C/C++ is popular.
C gained remarkable popularity as tools and systems made in C gained of widespread usage. Also, C is quite simple and can be mastered by any CS freshman in a few days or weeks. I guess this is why it's popular.

[>>1 pay attention, please]

C++, on the other hand, has a lot of interesting functionalities, but they showed up to be conflicting, resulting in a very verbose language, with lots of pitfalls that only can be mastered with enough time and practice.
Although it's really complicated, it took less time [for lots of previous C programmers] to learn a usable enough subset of C++, and use OOP/generics with their old C code. Taking time to learn a different OO/metaprogramming language and gluing them together with ffi didn't look as a sensible choice back then.

Time passes, and as the C++ code base grew bigger, the language problems showed up, such the slow compilation and lack of IDE/tools support. Newer languages like Java and C# worked around these problems and are much more popular than C++ by now. Also, JIT and GC improvemet made these languages available to performance-sensitive, but soft real-time, applications.

Today, the lack of an C++ ABI standardization and its great language complexity just make newer programmers to interface directly with C. Just use a scripting language, with tons of libraries, for soft tasks like GUI, logic and reading files [which are often backed by C libraries, like win32/gtk, libmpc and async OS calls], and leaving intensive computing tasks to custom written C functions with bindings [which are widely supported, instead of C++].

It's this, I don't think that “C++ is still the best choice”, and with this new trend called data oriented design, there isn't much place for C++ OOP anyway. Maybe at Google.

>>31
Informative post. Perhaps you can give me some guidance. I'm OP, by the way. I would like to write various tools to automate various professional tasks. For this, I agree that a scripting language is optimal.

But I also would eventually want (possibly need) to make simulations. For this, I've always been told that C++ was the way to go. Some programming boards I've been lurking pretty much make fun of Java/C# for being bloated. To what extent is this true? I've also been told that C++ is the most powerful language out there.

Should I just ditch C++ and go for Java and C? Are there any others you would recommend instead?

>>32

If you are doing simulations, then you will want to be able to perform calculations as quickly as possible. One thing that is nice about seeples is that you can set up your data structure, and then perform your calculations on it without invoking any new memory allocations. Not only do you avoid using a GC, but you can also avoid heap allocations by allocating your objects on the stack, since they will all have life time no greater than your calculation for each iteration of the simulation. And stack allocation is about as fast as it gets. The only thing better might be fixed locations in a global, static array, but this gets a little complicated if you are going to be using threads, since you'll need to make sure two threads don't use the same memory for their temporary variables. I'm not sure how much of a boost this would yield, or if it would help at all, or if it would be worth the effort. But anywho, in seeples you can do all of this explicitly. If you want things like that in c# or Java, you'll need to depend on an optimizing compiler to avoid using the GC while performing the calculations for each iteration of the simulation. But Java be fast. I've heard that Java with a just in time compiler can be around the same speed as C once you are no longer performing allocations.

>>10
5/10. Would be trolled again.

>>33
protip: I used to write simulations that used gc all day long in university and had no problem churning through the data at reasonable rates

5/10. Would be trolled again.

>>31
Guessing that you haven't worked in telecom/embedded real-time systems industry before.  In the high-tech industry, either you develop drivers in C/C++ and have job security for life if you are good or you develop testing tools in Java, Python and other scripting languages and are expendable and are fired immediately when times go bad.

>>34

It could have been fasta.

that feel when you remove all memory allocations from a tight loop, and the only data structure access is array indexing.

I never knew things could be so fast.

>>34

also an optimizing compiler may have been transforming your gc use to stack allocations, in which case, there would be no advantage to using a language like seeples.

do any of you actually work??

>>38

why do you ask?

>>35
I haven't worked in telecom before, but already “played” with some microcontrolers, and since you need to pay close attention to the generated assembly, C is much more straightforward.
Also, for the numerical simulations pointed out by >>32-33, C++ really can ease the task. But I would recommend using a simpler subset of the language, since you're most likely to use just POD structures with fixed data types, maybe templated ones.

The point here is that often these fast performing structures and methods are just a really simple and little core inside your application. OOP is great to help people build large and complex systems, but “large and complex” don't go well with “fast and optimized”. Just look at the computational approaches in any paper or application: you don't describe the problem as objects with parametrized types, inheritance and such, you just transform them to matrices and scalars, apply some heavy algebraic operations and then output them back again to your object-oriented user interface.

The optimizing JIT compilers today can do a pretty good job in these long running scenarios (like simulations), so you can just use any JVM language like >>34 said.
Or you can use QtQuick, which provides a nice javascript-like scripting language, form designers and a clean API, to build the GUI/IO portion of your software, and writing your own C/C++ code with custom sse/mmx/openmp code.

>>37
The point is that you don't really have control over memory usage outside static allocation. Modern JVMs are able to perform escape analysis by stack allocation or scalar replacement, for example, yet memory usage is still quite high, and not just because of virtualization.

>>41
It's only an issue when dealing with dense large graphs or matrices. By [b large] I mean greater than RAM, and that's my case.

>>42

I see. So were you reading portions of the data from a file as you were operating on them? And in seeples you could just buffer your stuff in a fixed data structure to avoid dynamic memory allocations, where in java you probably wouldn't be able to avoid some dynamic memory usage?

EXAMINE MY PROSTATE DUBS

>>43
Yeah, lots of short living objects, because they'll be replaced by the next chunk from file.

>>45

Interesting. If I was in that situation, I think I'd try to implement some method to overwrite the existing objects with the contents of the next chunk of the file. Somehow the file would need to be read directly into a buffer of some kind and then the bytes of the buffer would need to reinitialize your existing objects. I'm not sure how to do something like that exactly in java, but there is probably a way.

>>46
Your point is valid, I guess that I could do that with a couple of byte arrays. But I [i already] have a lot of legacy C++ code. So this is a no for now. But surely we'll fix this soon.

>>47

yeah, but you never know if it will really do the trick or not. It might be good to do a quick proof of concept using something simple (but pumped up to a massive scale) before investing the work required for making changes. I guess one could try making a 2d point class, writing 10000000 points to a file, and then reading all of them using a new Point2D(scanner); method, and one using a readNextChunkOfPoints(Point2D[] array, FileInputStreamThingyMaBob byteStream); and see if there is actually a difference.

I know and understand C++, but it's annoying as fuck to use. It takes long as hell to perform the simplest tasks. I only use it for performance-critical tasks. For everything else, there's always C# or Ruby.